Prior to the background of the invention being set forth, it may be helpful to provide definitions of certain terms that will be used hereinafter.
The term “file” as used herein refers to a container for storing data in a file system.
The term “directory” as used herein refers to a cataloging structure which contains references to other files, and possibly other directories. The term “file” includes the term “directory”.
The term “volume” or “logical drive” refers to a single accessible storage area with a single file system, In a distributed file system, files of a same volume need not necessarily stored on the same physical storage device (e.g. hard disk). From a client perspective however, files of the same volume are subject to the same rules and logic. It is the file system task to handle the management of the files on the volume in a manner that is transparent to the client of the file system.
FIG. 1 is a block diagram illustrating a general BranchCache architecture in accordance with some embodiments of the prior art. BranchCache is a wide area network (WAN) bandwidth optimization technology that is included in some editions of the Windows Server 2012 and Windows 8 operating systems, as well as in some editions of Windows Server 2008 R2 and Windows 7. To optimize WAN bandwidth when users access content on remote servers, BranchCache reads content from the main or central office 10 and caches the content at branch office locations 30, allowing client computers 52 and 54 at branch office 30 to retrieve the data locally.
When BranchCache is configured, Windows BranchCache clients first retrieve content (step 1—transfer document) from the storage system and then cache the content on a computer within the branch office (step 2—cache document). If another BranchCache-enabled client in the branch office requests the same content, the storage system first authenticates and authorizes the requesting user. The storage system then determines whether the cached content is still up-to-date and, if it is, sends the client metadata about the cached content (step 3—transfer identifier). The client then uses the metadata to retrieve content directly from the local host of the cache, if such data exists locally (step 4—retrieve cached document).
BranchCache increases end user productivity by improving content query response times for clients and servers in branch offices, and can also help improve network performance by reducing traffic over WAN links.
When implementing branch cache, the client is provided with a file data segment identifier, which is constructed using hashed file segment data and a unique server secret. Normally, when the branch cache feature is enabled, the first time a client asks for content file information of a certain file, the server-side will have to calculate the hashes for that file data. The calculated hashes are relevant until the next time the file is modified. As long as the file is not modified, same data segment identifier is used to identify file segment (file data segment is 64 KB chunks). Taking the same content file, the generated data segment identifiers will differ between two different servers.
When a volume is replicated to a secondary storage, a new volume is created on the secondary file system, wherein the replicated volume is an exact read-only snapshot of the original volume. Since this is neither the same volume nor the same file server, file segment identifiers will differ between source volume and destination volume.
So, even if the replicated volume contains the same content file information of calculated files, the segment identifiers will differ. Consequently, local branch cache segment identifiers for uploaded files will not be valid anymore if accessing secondary storage for the exact same unmodified file content.
Remote branch cache clients known in the art usually re-download the file content to local branch caches when connecting to replication destinations.
Some other solutions known in the art have an ability to change the server secret manually (using configuration interface) for the whole system (all virtual volumes at once). But this solution has a drawback of not being able to use some of the volumes as standalone, active, writeable volumes of a separate server, and other for replicated content.